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Abstract 

We describe a process calculus featuring high level constructs for component-oriented programming in a 
distributed setting. We propose an extension of the higher-order 7r-calculus intended to capture several 
important mechanisms related to component-based programming, such as dynamic update, reconfiguration 
and code migration. In this paper, we are primarily concerned with the possibility to build a distributed 
implementation of our calculus. Accordingly, wc define a low-level calculus, that describes how the high-level 
constructs are implemented, as well as details of the data structures manipulated at runtime. We also discuss 
current and future directions of research in relation to our analysis of component-based programming. 

Keywords: Distributed computing, component-based programming, process algebra, higher-order calculi, 
abstract machine. 



1 A Core Calculus for Dynamic Modularity 

1.1 Motivations of this Work 

This paper describes work on component-oriented programming and the 7r-calculus. 
Our long term goal is the design and implementation of a prototype programming 
language meeting the following requirements. 
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• It should be suitable for concurrent, distributed programming. For instance, usual 
distributed, parallel algorithms should be easily implementable, as well as lower- 
level communication infrastructure for networks. Furthermore, it should enjoy a 
well-understood and tractable behavioural theory. 

• It should provide constructs for modularity, in the standard, informal sense that 
programs should be built as an assembly of relatively independent computation 
units (or modules) interacting at explicit interfaces. Moreover, modularity should 
come with encapsulation features, e.g., it should be possible to exchange two 
modules implementing the same interface without affecting the rest of the code. 

• The modular structure of programs should be available at execution time, so 
as to ease standard dynamic operations such as migration, dynamic update, or 
passivation of modules. We call this requirement dynamic modularity. The notion 
of dynamic modularity gathers the most challenging features of component based 
programming we are interested in modelling and analysing. 

• Finally, we are seeking a reasonably implementable language, at least permitting 
rapid prototyping of distributed applications. 

In this paper, we describe our proposal for a core process algebra to represent 
and analyse dynamic modularity (this section). In designing this formal model, we 
have put a stress on the possibility to deploy and execute processes in a distributed 
fashion. In Sect. 2, we describe our prototype implementation by defining an ab- 
stract machine for the distributed execution of processes. This description is given 
via the definition of a new process calculus, where low-level aspects related to the 
implementation (notably, communication protocols), as well as the data structures 
at work in the machine, are made explicit. 

1.2 Syntax and Semantics of kn 

In order to provide a formal treatment of the questions described above, we study 
an extension of the higher-order 7r-calculus, called kir. We choose the 7r-calculus 
for two main reasons: first, message-based concurrency seems an appropriate choice 
to define a model for concurrent programming at a reasonable level of abstraction. 
Second, working in the setting of a process algebra like the 7r-calculus makes it 
possible to define a core formalism in which we can analyse the main questions, 
both theoretical and pragmatic, related to the implementation of primitives for 
dynamic modularity. Third, we might hope for this to benefit from the considerable 
amount of research that has been made on 7r-calculus based formalisms. 

Our calculus inherits ideas from numerous previous studies, among which [8,7,3], 
and in particular the Kell calculus [2,14]. The grammar for processes is given in 
Fig. 1 - we suppose two infinite sets of names (a, b, m, n, k, x) and process variables 
(X,Y). In addition to the usual 7r-calculus constructs, we have modules, n[P], 
which can be seen as located processes (note that modules can be nested). M.P 
is a process willing to emit (first- or higher-order) message M and then proceed as 
P. Rt> P stands for a process willing to acquire a resource: this can mean either 
receiving a first- or higher-order message (cases a(x) and a(X), respectively), or 
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P,Q::= P\P\ {un)P \ | n[P] \ n[X] \ M.P \ R> P (processes) 

M ::= a(n) | a(P) \ a(X) (output prefixes) 

R ::= a{x) | a{X) | n[X] (input prefixes) 

E ::= [ | E | P | (im)E | n[E] (evaluation contexts) 

Fig. 1. kir: Syntax for processes, evaluation contexts 



a, b g capt(Ei) U capt(E 2 ) 

K-COMM 



K-CommHO 



EpEi[a(6).P] | E 2 [a(x)>Q]] ->EpEi[P] | E 2 [Q{b/x}}} 

fn(P') n (capt(Ei) U capt(E 2 )) = 
E\E 1 [a{P').P] | E 2 [a(X)>Q]]^E[E 1 [P] \ E 2 [Q{P'/X}]] 



K-Pass 



K-CONGR 



E[n[P] | n[X]>Q] -» E[Q{P/X}} 
P' = P P^Q Q = Q' 



P'^Q' 



Fig. 2. Operational Semantics of kir 



passivating a module. The input prefixes and restriction are binding constructs, 
and we write fn(P) for the free names of process P. {b/x} (resp. {P/X}) denotes 
the capture avoiding substitution of name x (resp. process variable X) with name 
b (resp. process P). 

Notice that a process variable (X) does not form a process by itself: it has to 
be enclosed in a module (npf]) or a message (a(X).P). This restriction mainly 
ensures that the content of several modules cannot be merged into a single module; 
this helps simplifying the implementation of the calculus. 

Fig. 2 presents the rules defining the reduction relation, — It makes use of 
evaluation contexts, which are processes with a hole that does not occur under a 
prefix (Fig. 1). Given an evaluation context E, we define the set of captured names 
in E, written capt(E), as the set of names that are bound at the occurrence of the 
hole in E. The definition of — ► makes use of structural congruence, =, the least 
congruence satisfying the following axioms: 

P\0 = P P\Q = Q\P P\(Q\R) = (P\Q)\R 

(uc){vd)P = (ud){uc)P (vc)(P\Q)=P\{vc)Q\fc£hx{P) (uc)0 = 
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kl 



k2 




k3 










Fig. 3. A configuration. 

An example ktr process. 

A kn term represents a configuration consisting of a hierarchy of modules, in 
which processes are executed. To illustrate the mechanisms at work in kir, we briefly 
discuss an example configuration. Given some kir processes P, P[,Qi Fig. 3 depicts 
a process of the form 

(ua)(m[P] | ni [P{ | n 2 \P' 2 j n 3 [P£]} | k x \(yb){Q x \ k 2 [Q 2 ] \ k 3 [Q 3 ])}) 

(note that the localisation of the restrictions on a and b does not appear on the 
picture). There are basically two forms of interaction in k-rr: communication and 
passivation. Communication involves the transmission of a name or a process; it is 
distant, in the sense that a process a{b).P can synchronise with a receiver a{x) o Q 
sitting in a different location, provided they share the name a. On the picture, a 
process running in k 3 can exchange messages with another one in n 3 (using channel 
a) , as well as with a third process running in k 2 (using channel b) . On the contrary, 
passivation is local: only a process running at n\ is able to passivate module n 2 . 
This is described by the third axiom of Fig. 2: up to structural congruence, the 
module being passivated and the process that takes control over it must be in 
parallel. Passivation is a central construct in our formalism, and can be used to 
implement very different kinds of manipulations related to dynamic modularity. For 
instance, taking Q = n'[X] in the above reduction leads to a simple operation of 
module renaming; with Q = c(X), the module n will be 'frozen' and marshalled into 
a message to be sent on channel c; finally, taking Q = n[X] \ n'[X] makes it possible 
to duplicate a computation. When considering the actual implementation of the 
behaviour of kn processes, it appears that the last two examples clearly involve 
much more costly operations than the first one. 



1.3 On the Design Choices in the Definition of kn 
1.3.1 Restricted names as localised resources 

An important commitment that we make in the design of k-rr is that, contrar- 
ily to several existing proposals, we do not allow channel names to be extruded 
across module boundaries: neither do we include an axiom of the form n[{ub) P] = 
(vb) n[P] in structural congruence, nor do we implement name extrusion across 
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modules along reduction steps that would require it. 

This design choice is related to the notion of module that we put forward in kir: 
if we were to allow name extrusion, some processes would admit two legitimate but 
very different reduction paths. Take indeed 

P d = m[(ua)b{a).P] | b(x).Q | m[X]>( mi [X] | m 2 [X]) . 

We would have the following sequences of reductions: 

P -» (ua)(m[P] | Q{a/x} \ m[X) > (rm[X\ \ m 2 [X])) 
-> {ua)(Q{a/x} | mi[P] \ m 2 [P}) 
and 

P^b(x).Q | mx[(va)b{a).P] \ m 2 [(ua)b(a) .P] 
-> (i/a)(Q{a/z} | m x [P]) | m 2 [(ua)b(a} .P] 

We claim that none of these paths is fully satisfactory, and that such a situation 
should be avoided - the choice between these two behaviours being left to the user, 
through explicit programming. Therefore, we interpret the names declared inside a 
module as private resources, that should remain local to that module. Passivating 
module n hence means getting hold of the local computations, as well as of the 
resources allocated in n. Typically, names allocated in module n can be viewed 
either as temporary resources allocated for the computations taking place at n, or 
as methods provided for sub- modules of n, for which n acts as a library. 

As a consequence, the user is made aware of the localisation of resources; this 
choice also helps considerably in the implementation of kn, essentially because we 
always know how to route messages to channels (see below; a similar idea is present 
in existing implementations of 7r-calculus-related process algebras, such as [4]). At 
the same time, this hinders the expressiveness of message passing: a process willing 
to send a name n outside the module where the restriction on n is hosted is stuck. 
Consequently, for two distant agents to share a common name, this name should 
be allocated at a place that is visible for both, i.e., above them in the hierarchy 
of modules. In other words, extrusion is not transparent to the user, and has to 
be programmed when necessary. Of course, there are situations where one would 
like to allocate a new name outside the current module. It turns out that a corre- 
sponding primitive for remote allocation, vn@m, can be added at small cost to our 
implementation (Sect. 2). 

Experiments with examples written in kn show that the idioms we would like to 
be able to program are compatible with the discipline we enforce in our formalism. 
Further investigations need to be made, in particular with larger examples, in order 
to understand the possibilities offered by programming in kir. 

1.3.2 Modularity vs. physical deployment 

It should be noticed that the hierarchy of modules described by a kir process does 
not necessarily correspond to a given mapping from modules to physical sites. We 
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Fig. 4. Some kir configurations 



show on Fig. 4 some examples illustrating how we intend to use kit processes to 
express typical situations in distributed programming. In the top left diagram, a 
host module H contains a library module L, as well as two other sub- modules X 
and X' . X and X' are connected with module L via some names residing at H. 
Physically, this can well correspond to a situation where H and L are run on the 
same site (the site that provides the library), while X and X' are on (possibly 
distinct) distant machines, and rely on remote communication to interact with L. 
On the top right diagram, a process in H has passivated L [H and L are co-located, 
physically) to replace it with an updated version of the library (L'). 

The bottom left diagram depicts a different scenario, based on the same "mod- 
ularity pattern": here, several sites provide the services of library L, and welcome 
the users of L. In this configuration, all sub-modules of a given module are executed 
on the same machine. It might be the case, for load balancing purposes, that one 
host passivates a local client to send it over the network to another location: this 
is illustrated on the bottom right diagram. 

2 A Distributed Implementation 

In this section, we describe a distributed abstract machine that implements kir. 
This machine abstracts from issues such as data representation, to focus on the 
implementation of distributed communication in the presence of passivation. The 
design of this machine has been tested on a prototypical distributed implementation, 
so as to make sure that our implementation choices are reasonable (see [9]). 

2.1 Implementation Choices 

Before moving to the presentation of the formal definition of our abstract machine, 
we give a high-level view of how it works. This should help in following the more 
technical explanations we give in Sec. 2.2. 
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Computation units. 

The first (standard) feature of our machine is that it flattens the hierarchy of 
computation units: for example, each of the seven modules composing the program 
of Fig. 3 is executed in its own asynchronous location by the machine. In order to 
retain the tree structure, each location stores and maintains the list of its children 
locations. As expected, when a module creates a sub-module, the latter is spawned 
in a fresh location. In order to make sure that locations can be implemented in an 
asynchronous way, we let them interact only by means of (asynchronous) messages. 

Communications. 

The protocol for distant communication is rather standard: a process willing 
to send a message sends it to the location holding the queue that implements the 
channel; accordingly, a process willing to receive a message sends its location to the 
queue location and suspends execution, so that it can be awaken when a message 
is available. Using our interpretation of modules, the natural location to run the 
channel queue is that of the module that created the name; this is made possible 
by our choice to prevent the channel name from being extruded out of this module: 
if the module gets passivated, all of its sub-modules too, so that any process trying 
to communicate on the channel will get passivated as well. 

Passivation. 

Passivation cannot be atomic, because the hierarchy of modules has been flat- 
tened, as described above (this departs importantly from the machine in [1]). Thus, 
we implement it in an incremental fashion, from the passivated module down to its 
sub-modules, transitively. Along the propagation of a passivation session, we must 
handle two main sources of interferences. 

• First, in the case where some sub-module has already started a passivation, our 
machine gives priority to the inner passivation session - the other option would 
have been to cancel the latter and let the dominating passivation proceed instead. 

• More importantly, we need to clean up running communication sessions in the 
passivated sub-modules. As explained above, this is not problematic for com- 
munications on names belonging to the passivated module. For communications 
on names that reside above the passivated module, we use simple interactions 
with the modules owning the involved channels: status messages are used to 
query whether commitment to a communication already occurred, so that the 
computation can be either completed or aborted. 

Distributed Implementation. 

We have written an OCaml implementation of this abstract machine [9]. This 
implementation exploits two libraries: one for high-level communications, where 
message passing is executed either as memory write-ups or as socket communication, 
depending on whether it is local or distant; and another one for communication, 
thunkification and spawning of OCaml threads, together with their sets of defined 
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a, n, x, u, h,g,s G Names 
X G PVars 



(Names) 
(Process Variables) 



B : 


:= fx) 


1 (X) 


1 [XI 1 (a) I (P) 


1 (X) 


(Binder / Argument) 


P : 


:= 


P | P 


(va)P n[X] 


aB>P 


(Process) 


V : 


:= u 9 


K 


• | —i 




(Value) 


G : 


: = 


G G 


1 s(h u V) 1 s( ? 




("Rfifliifist 1 


I : 


:= P 


I\l\ 


u s (aB>P,M) 


a s (V) | 4(7) 


(Local state) 


P ■ 


:=0 | 


p,a^ 


u 9 p,X ^ K 




(Table) 


K : 


:=/; 


p ; 9 






(Thunk) 


M : 


:= 


Hi) | 


9(G) 




(Messages) 


S : 


:= M 


| s \ s 


| {ua)S | /i[ET] | 


g[G] 


(State) 




■= MO 


\I\P 


;g] 




(Contexts) 






\G] 









Fig. 5. Syntax of the abstract machine. 

names (to optimise the process of passivation, the data structure implementing a 
module comes with a table collecting all names known by the module). Finally, 
each syntactic construction of the language is compiled into a simple function that 
uses the previous libraries along the lines of the formal specification of the machine 
we describe below. In particular, we do not need to manipulate explicit abstract 
syntax trees at runtime. 



2.2 Formal Definition of the Abstract Machine 

The abstract machine for the distributed execution of kn processes is defined as a 
process calculus, where details about the data structures we use in the implemen- 
tation and about the protocols at work are made apparent. 



Configurations of the Abstract Machine. 

Fig. 5 presents the grammar for the abstract machine. As previously, we rely 
on two infinite sets of names {Names) and process variables (PVar); names will 
be used for ktr processes as well as for various internal identifiers required by the 
machine: allocated name identifiers (u), logical locations (g,h), and session iden- 
tifiers (s). Moreover, we let i range over relative numbers (Z). Although they are 
presented in a slightly different way, processes (P) of the machine are essentially 
the same as previously: the only difference is that we allow modules to contain 
process variables only (the entry n[P] disappeared, only n[X] is left). To obey this 
constraint, we recursively define a pre-compilation step mapping processes of the 
calculus (as defined in Fig. 1) to those of the machine (Fig. 5); the only non-trivial 
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case is: 



ln[P}^ = (ua){a(lP^) > | a(X) > n[X\) 



(where a is a fresh name). The final translation from closed source processes to 
states is the following, where h and g are two arbitrary distinct names: 



At runtime, this state will evolve to a state where each module (node) of the 
tree structure of P is represented by a configuration of the form h[K] | g[G], where 
K = I ; p ; g is a thunk, and: 

• h is a low-level logical location; several such locations can be executed on the 
same physical location; 

• I is the local process being executed, together with some state information; 

• g is the address of another associated low-level logical location, where names 
allocated by the module will be handled (with the help of G) - we call g the 
top-level communication channel of K; this channel is recorded in K in order to 
allocate new names. 

• p is a table (or environment) binding process variables to thunks, and names to 
pairs of the form u 9 : u is a unique identifier and g' is the channel where the name 
is handled. 

In the OCaml implementation h and g correspond to two channels (implemented 
either with shared memory or with sockets, depending on the physical locations of 
the endpoints). In turn, K and G correspond to two threads, listening to those 
channels. Messages transmitted on these channels are of the forms / and G, respec- 
tively. 

We explain the various syntactic entries together with the operational semantics, 
given below. Tables are seen as partial functions from names and process variables 
to values; these functions are recursively extended to binders and arguments (entry 
B in the grammar) as follows: 



lP] = (vh,g)(h[lPyj;g]\g[0]) 



P«a» 
P((P)) 
P((X)) 



p{a) 

{P 5 P',9) (for some g £ fn(p)) 
P{X) 



p((x)) = p{{X)) 
P([X}) 



is 



undefined 



The following operation will be useful in order to extend tables: 



p, x i — ► vP if B = (x) and V = u 9 ; 
p + B ^ V = < p, X ^ K if B = (X) or B = [X], and V = K ; 
p otherwise. 
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We will also need the following substitution operation on thunks: 

K is} = i{g/g'} ; p{g/g'} ; g where k = i ; p-g . 

Operational semantics. 

We have enough material to explain the operational semantics of the abstract 
machine, which is presented in Fig. 6. The first three rules are standard; structural 
congruence is not defined here, it contains no surprise: structural congruence of 
source kn processes is inherited; parallel compositions and elements form associa- 
tive commutative monoids; and alpha-conversion and scope-extrusion are allowed. 
We explain the other reduction rules below; they make use of contexts (Hr£, G g - 
see Fig. 5) in order to focus on single logical locations (we omit p, h or g when they 
are not relevant for the rule). 

• Communication. 

• In rule I-Req, a prefixed process is executed by sending a request s(h, u, V) 
(for reception or for emission, according to the shape of B) on the channel that 
handles the communications taking place on a. A fresh session identifier, s, 
allows us to uniquely identify this part of the communication protocol. The 
process waiting to resume computation is stored locally in an element of the 
shape uj s (aBs>P, M); message M will be sent in case a passivation occurs before 
the communication actually take place - we explain this protocol below. Notice 
that this rule does not apply if B is of the form [X]: in this case, p(B) is 
undefined. This situation correspond to a passivation prefix, which is handled 
by rule I-StartPass. 

• Rule I-Compl describes how a successful completion message unleashes the 
continuation of a prefix action: a message a s (V) meets an element uj s (. . .) with 
the same session identifier (s): the continuation process (P) is released, and, in 
case we are on the side of the receiver, a new binding is generated and added 
to the table of the local process (p). 

• In rule I- Abort, a message of the shape a s ( _i ) tells the frozen process to undo 
its commitment: the original prefixed process is installed again. As we shall see 
below, this may occur in case of a passivation. 

• Routing. 

• Rules I-Route and I-Route' are used to transmit messages on both kinds of 
channels to their actual destination channel. 

• Rule I-Comm describes how two requests for emission and reception, respec- 
tively, occurring on the same name identifier u, and originating from locations 
hi and /12, meet: downwards acknowledgment messages are generated, with 
the identifying session names; the content of the message is transmitted to the 
receiver process. 

• Rule I-Stat shows how messages for cancelling commitments (a s (-i)) are gen- 
erated: this happens when a message requesting communication gets caught up 
by a status message s(?) (see rule I-PassSess below). 

• Distribution. 
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Contextual closure 

s — > s' s s' S = So So — > Sq Sq = s' 



So I S -> So I S' {va)S -» {va)S' S -> S' 

Communication 

p(a) = u 9 p(B) = V si fti(H?[aB > P]) 



I-Req 



U p h {aB>P] (v S )(g{ S (h,u,V))\Il p h [uj'>(aB>P,g( S (?)))}) 



I-COMPL 

V ^ -i ()'=/) + BhV I- Abort 



H"[w s (aS>P,_) | -> H p [P] H[^ s (aS > P, .) | a s (^)] -» M[aB > P] 

Routing 

I-ROUTE r rr; — ; — ; I-ROUTE' — - — — — 

Gg[0] I 9(G) - G 9 [G] H h [0] | h{/> - H h [/] 

I-COMM 

G[ S1 (7ii,u, V) | s 2 (h 2 ,u,.)} -» G[0] | Ma si (»)> I fe 2 (« S2 (V)> 

I- Stat 

G[s(/i,u, V) | s(?)] -» G[0] | h(a s (-n)) 

Distribution 

a, u i in(h[I | (ua)P ; p ; g}) 



I-Fresh 



I- Spawn 



I-StartPass 



I-PassSess 



h[I I (isa)P ;p;g]^ (uu)h[I \ P ; p, a ^ u<> ; g] 

p(X) = K h,g£fri{W h ,[n[X\}) 

M^[n[X]] -» | g[0] \ U?, [w h (n[X] > n[X] , fc(«&'(0)»]) 

Passivation 

M ^ 



[[n[X] >P | a^HX] >n[X], Af)] -> H[w' l (n[X] > P, 0)] | M 
M + 

'[Ki(I) \ cu s (aB t> P, M)} ->M[Ki +1 (I \w s {aB>P,0))] \M 



I-Decr I-Pack 



K"(/) | a(V)] - H^tiC/ | a(V))] h'[P | «*(!) ; p ; g] -» h(a h '(P|/ ; p ; «,)> 



Fig. 6. Operational semantics for the abstract machine. 



Rule I-Fresh shows how kn names are allocated: a new identifier u is generated, 
and we store in the local table the information that communications on name a 
are handled with identifier u by the top-level communication channel g, which 
is associated to the current location (h). 

Rule I-Spawn is the most complicated rule: it spawns a new location, in order to 
execute a sub-module of the current module. As explained above, this involves 
generation of two channels, one (h) for executing the code of the sub-module, 
and another [g) to handle communications on channels allocated by that sub- 
module {g is the top-level communication channel). 

A sub- module waiting to be executed is of the form n[X]. The local table 
(p) tells which thunkified computation is associated to it (K). This thunk has 
been previously linked to a top-level communication channel, that was used to 
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handle communication channels (K might be a process that has been running 
and allocating names for some time, before being passivated). Since this channel 
cannot be used anymore (because the thunk may have moved physically, or been 
replicated) a new channel (g) and a new thread (ff[0]) have to be created, and 
we need to replace the old address with g in all tables that can be found in K, 
whence the update K{g}. Note that in the actual implementation, thanks to 
the use of tables, applying this substitution does involve inspecting the code 
at runtime: we only perform an operation on tables, which are runtime data 
structures to supervise the execution of the code. 

The tricky part of the rule is the element a;' l (n[X] >n[X], /j(kq (0)}) which 
is left in the parent location after the sub-module has been spawned. This 
element allows us to recall that h is a child of h' in the original tree hierarchy; 
it will be used in two ways, in case the parent location wants to passivate this 
child, or gets passivated. These two cases respectively correspond to the rules 
(I-StartPass,I-PassSess) presented below. 

• Passivation. 

■ Rule I-StartPass initiates a passivation protocol: the current module wants 
to passivate a sub-module named n, and we know that there is such a sub- 
module thanks to the element of the form io>(npT] > n[X], M). It suffices to 
release message M: according to rule I- Spawn, M is of the form h(K^ (0)), 
where h is the location of the child, and we shall see in the remaining rules that 
upon reception of that message, the sub-module will passivate itself and send 
its thunkified version back to h' , the parent location. Moreover, we update 
the w-element so that it will yield the expected result upon reception of the 
passivated child, through rule I-Compl. Notice that it is important to check 
that M 7^ 0: otherwise, in case P is of the form n[X], we could incorrectly 
apply the rule twice. 

• Passivation gets propagated to the whole sub-tree by rule I-PassSess: the re- 
element acts as a buffer that records the current state of the passivation, and 
accepts any element of the form uj(_,M) by sending message M. This may 
correspond to two situations: 

- the w-element denotes a sub-module, in which case the message tells the 
sub-module to passivate itself, recursively; 

- the w-element corresponds to a pending request for communication. In this 
case, due to rule I-Req, M is of the form g(s(?)): by sending this status 
message, we force g to answer the request (if the completion message was just 
sent, nothing happens, the status message gets lost; otherwise, rule I-Stat 
applies, yielding an abortion message /i(s(— >))). 

In both cases, we increment the counter stored in the re-element: we need to 
record that we have to wait for an answer (an a-message). 

• Rule I-Decr allows the re-element to consume those answers, by buffering them, 
and decrementing its counter. 

• Finally, rule I-Pack can be used after the whole state has been cleaned: only 
a source process, P, remains in the location; all uj and a-elements have been 
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integrated to the K-buffer, and the K-counter is null. The buffer, the remaining 
source process, the current table and the address of the current name handler, 
g, are sent back to the parent location (/i), and the thread running at h is killed 
(we could also send a message to the associated channel (g) in order to kill 
the corresponding thread - we omit this garbage collection optimisation for the 
sake of simplicity). 

2.3 Related works: abstract machines for distributed computation 

Several works on the implementation of process calculi for distributed programming 
have focused on Ambient-like models (Mobile [5], Safe [6,10], Boxed [13]). We 
have already mentioned [1], which introduces an abstract machine for the Kell 
calculus. The most important difference between this work and the previous ones 
is the presence of the passivation operator in the calculus, which is the source of 
delicate questions when it comes to actual implementation, kn is related to the Kell 
calculus. The machine we have introduced provides a more fine-grained presentation 
of distributed interaction; in particular, passivation involves a complex distributed 
protocol, while it is atomic in [1]. 

We come back to these related studies in the next section, when discussing the 
formal validation of our machine. 

3 Concluding Remarks 

The process of the definition of kit and the study of its implementation have raised 
several questions, that we are currently investigating, or that we want to address in 
the future. 

3.1 Ongoing Work 

A type system to prevent illegal name extrusions. 

In order for the machine to work correctly, we need to make sure that names 
are not extruded outside their defining module. A solution would be to inspect 
the content of each message at runtime, and to block illegal communications. To 
avoid the inefficiencies induced by this approach, we want to rely on a type system 
to enforce statically this confinement policy: a well-typed term never attempts to 
extrude a name out of its scope. 

The type system we are studying exploits an analysis of the hierarchy of modules 
to detect ill-formed communications. An output a(n) is licit only if the restriction 
binding n is above the one binding a in the structure of modules (or if n is free 
in the process). If, instead of a or n, we have names bound to be received (as in, 
e.g., c(x) >a{x)), then the type information associated to the transmitting channels 
gives an approximation of the module where the names being communicated are 
allocated (intuitively, this information boils down to "name x is allocated above 
module named m and under module named k" — both pieces of information are 
necessary, because the name instanciating x may then be used either as medium 
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or as object of communication). The communication of process values follows the 
same ideas: in a{P), we impose that all free names of P should be allocated above 
a. Consequently, in the type of both module names and of channels over which 
processes are transmitted, we provide a spatial bound of this kind on the free names 
of the process being executed (resp. communicated). 

In addition to the standard property of subject reduction, correctness of our type 
system is expressed by showing that every typeable process is well scoped, which 
intuitively means that such a process does not attempt to emit a name outside 
its scope. Since this property is preserved by reduction, we can avoid checking 
for scope extrusions at run time. Although we need to experiment further with 
the expressiveness of our type system, preliminary attempts show that the policy 
enforced by our system is reasonable, in the sense that the examples we have in 
mind can be typed in a rather natural way. We defer the presentation of the type 
system, as well as the corresponding correctness proof, to a future presentation of 
our work. 



Correctness proof for the abstract machine. 

The abstract machine of Sect. 2 provides a rather low- level description of how 
kn processes should be executed in a distributed setting. Proving its correctness, 
i.e., that the result of the compilation exhibits the same behaviour as the original 
source process, is a challenging task. Examples like [5,10] illustrate this — on the 
contrary, machines like the ones in [2,13], by providing a more high-level account of 
the implementation, make it possible to build simpler correctness proofs. The main 
difficulty is that proofs of this kind tend to be a really large piece of mathematics; 
appropriate techniques are necessary to render them more tractable, in order to 
be able to complete them. This is the case in our setting, notably because the 
passivation mechanism brings several technical subtleties. 

The reductions of a kir process and the execution of a machine state are de- 
scribed by two transition systems. We could hope to establish a bisimulation re- 
sult, providing evidence that the compiled version essentially exhibits the same 
behaviour as the source process. However, because passivation is not atomic in 
our setting (contrarily to [1]), this is not possible. Indeed, consider the following 
process: m[a(u) \ n[b(v)]] \ m[X] >Q. The actual execution of the passivation of 
m may go through a state where the emission on b is blocked while the one on 
a is still active; such a state has no counterpart in the original calculus. Instead, 
correctness of our machine should be stated as a coupled bisimulation result [12]: 
although this behavioural equivalence is weaker than plain bisimulation, it entails 
operational equivalence (any kn reduction step can be simulated by the machine, 
and any reduction step of the machine can be completed into a step of the calculus). 
It can be noted that the correctness proof for the machine of [13], which comes in 
two parts (soundness and completeness) , is conceptually close to a 2-simulation re- 
sult, which in turn is obtained by dropping a clause from the definition of coupled 
simulation. 
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3.2 Future Extensions 

Optimisations of the machine. 

The definition and implementation of the abstract machine plays an essential role 
in the design of kir, because it provides practical insight on the main design decisions 
behind the formal model. In addition to that, the implementation also suggests 
several improvements or extensions, that we would like to study further. We have 
already mentioned the primitive for remote name allocation vn@m, an operation 
that in principle can be encoded, but comes at a very low cost as a primitive, given 
the current design of the machine. Another direction worth investigating is how 
the general behaviour of the machine can be specialised by taking into account 
information such as, e.g., the fact that a whole module hierarchy runs on a single 
machine. 

Module Interfaces. 

As it is, the type system we have sketched above associates rudimentary infor- 
mation to a module name, which is only related to the regions accessed by processes 
running within this module (properties like "this module has only access to refer- 
ences situated above module m"). It would be interesting to define more informative 
module interfaces, that would in particular describe some aspects of the behaviour 
associated to the usage of the names hosted by the module (as well as the interfaces 
associated to sub-modules, recursively). One could think for example of having the 
type of a channel c describe the arguments that are expected to be sent on c. To go 
beyond that, the possibility of expressing expectations in terms of resource access 
and consumption would be helpful. Also, finding meaningful type disciplines to 
control usages of passivation is an interesting question as well (a simple example is 
the possibility, for implementation purposes, to be able to guarantee that a passi- 
vated process will be used in an affine way - that is, without duplication - by the 
passivating agent). Existing type systems for 7r-calculus based formalisms, as well 
as for object-oriented languages, should be sources of interesting ideas to investigate 
these issues. 

Handling (re)binding. 

In its current form, kir only makes it possible to implement limited forms of 
dynamic modularity. When a module is passivated, it can be moved around, du- 
plicated, and computation can be resumed, as long as the confinement constraints 
associated to the localisation of restrictions are respected. In writing examples in 
kir, it appears that it would be helpful, when passivating a module, to be able to 
somehow disconnect it from some of the local resources it is using. This would make 
it possible to send the passivated module outside the scope of the names it was us- 
ing, possibly to another site where computation can be resumed after connecting 
again to another bunch of resources. 

Extending kir with mechanisms for dynamic (re) binding while keeping the pos- 
sibility to assert statically properties of modules about their usage of resources is a 
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difficult task. The work on Acute [15] may provide interesting inspiration for this. 
From a more low-level perspective, we believe that the tables that are manipulated 
at run time in our machine are well-designed to support such an extension. 



Behavioural equivalences. 

Not only do we want to execute kn programs, but we also would like to state and 
prove their properties. At a foundational level, we would be interested in analysing 
the notion of behavioural equivalence provided in k-rr, and in understanding the role 
of passivation in this respect. The work of [11] goes in this direction (as well as [8], 
in the setting of the Homer calculus). 
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